JSConf.jp おかわり Node学園46時限目
https://www.youtube.com/watch?v=q5ZkrvP46RQ
<permisson>要素
現在のブラウザにおける権限管理
それは使いやすいのか？
問題点
どの要素がどの権限のリクエストがセマンティックに表現されていない
"permanent deny" policy
リクエストを何度も遅れないようにする背景
課題
課題を２つに分けて代替え案を検討
Motoki Shakagori
サービス概要
https://gyazo.com/6c5f2128cd0ecc6ffae06748c13ad1d7
コンテナはデプロイが重い
開発体験がよいので使ってみたい気持ちがある
検証段階をすぎても脱出は容易と判断
とはいえそれで困ったことはいまだにない
ローカル開発環境
dev server立ち上げからdeployまで担う
dev serverは本番と同等のランタイムで動く
tsも事前のコンパイルなしで実行可能（型検査は別途実行する必要あり）
Cloudflare KV, R2などのCloudflareサービスのエミュレータ付き
テスト
Cloudflare公式の@cloudflare/vitest-pool-workersというVitestプラグインを使う 責務
サーバーサイドでコードを実行できるので、DB呼び出しを含むビジネスロジックも全てRemixの中に書くことも可能 今回の開発では、APIからデータを取得して整形するだけのBFF的な役目に徹する 非同期処理のバッチなど
Workers間の通信が非常に高速で分離するコストが低い
通信について
code:json
// service-aというWorkerからservice-bというWorkerを呼び出す場合
{
"name": "service-a",
"services": [
{
"binding": "SERVICE_B", // コードから呼びだすときの名前
"service": "service-b", // デプロイするときにつけた名前
},
],
}
インターフェースはfetchなのでHTTP越しのやりとりにしか見えない
移植性が高くなっている
別のクラウドにうつってもコードの見た目が変えずに移行が可能
code:index.ts
export default {
async fetch(request, env) {
return await env.SERVICE_B.fetch(request);
},
};
code:server.ts
import { Hono } from "hono";
const app = new Hono()
.get("/hello", (c) => c.json({ message: "Hello, World!" }))
.get("/dog", (c) => c.json({ face: "🐶" }));
export type AppType = typeof app;
export default app;
code:client.ts
import { hc } from "hono/client";
import type { AppType } from "./server";
await client.hello.$get().then((res) => res.json()); // { message: string }型
await client.dog.$get().then((res) => res.json()); // { face: string } 型
@sentry/cloudflareがあるので動く
エラーとトレースのみ
現時点ではプロファイルは取れない
分散トレースもバッチリ
失敗したらどうするの？という問いに答えをもっておきたい
現状認識
JSフレームワークは制約があるので当てはまらない
しっくりこない＝悪くないけど良くもない、モヤモヤ
サーバーが一分かかっている
ソフトウェアアーキテクチャとは何か
保守性に全振りしたソフトウェアの形状をもとめる形？
Webフロントエンドの品質特性って？
アクセシビリティ
セキュリティ
プライバシー
デザイン
アーキテクチャドライバ
変えられない設計判断のこと
バックエンドとの違い
https://gyazo.com/599e45472bc4cdf50832f71edf4a72cf
実行環境の多様性
状態管理
ビジネスロジック
パフォーマンス
信頼性
ユーザービリティのために再レンダリングさせたい
インスタンス比較より値の比較のが早いし簡単
OOPは決定は遅ければ遅いほどでいい世界線
でも決定が遅れると使っているかどうかがわからない、ブラウザへ持っていくほかない
隠されているものがないと削れるものが増える
スタイル変更の背後にはトレードオフの解決
日常のブラウザ操作も自動化ができるがそれ以外もできるのではないか？
ローカルファイルを監視
ファイルが更新されたらページ内のエディタに投入する
監視する
viewportは常に固定
1280x720
ダイアログで自動で閉じる
window.alert, window.confirmは自動的に閉じる
locatorでDOM要素をつかんでClickしてからpressSequentiallyでキー入力を流し込む
WebページからNode.jsにシグナルを送るには？
addEventListnerする
プロセスが分離しているからできない
案１
DOM要素を監視する
DOM要素をイベントベースで監視できない
案２
Page.exposeFunction
Webページに関数を登録できる
実態はRPC
案３
API Testing機能
ダミーHTTPサーバーを差し込める
双方向通信ができそう
既存のフレームワークのCustom Elementsビルド機能
Custom Elementsとしてビルドするフレームワーク
ケースにはよるけど基本こちらに寄せたい
バンドルサイズで不利
フレームワークの将来的に見てサポートするとは限らない
LitのAPI設計
プリミティブな部分まで分割している
LitElement
ReactiveElement
問題は解決した？
Custom-elements-manifest
propsの抽出
defineComponentPropsメソッド
型パラメータとしてpropsの情報を記述
cemの抽出をするだけ
cemを元にラッパーコンポーネントを生成する
増減がある、時差が変更になる、名称が変わる
2023年は4回変わった
春頃：夜中の1時間がなくなる
秋頃：夜中の時刻が2回くる
旧暦、ユダヤ歴、イスラム暦
1年が同じ月あるわけでもない
日時に関する仕様・リソース
HTTPでも継承
JSの標準フォーマット
Data.prototype.toUTCString()で生成
IANA TZ database
BCP 175に定められている
iCalendar RFC 5545
Ja-JP
RFC 5646, RFC 4647
Set系のメソッドが破壊変更
計算系のユーティリティメソッドがない
formatToParts()
今後は何を意識すべきか
日時はなにを意識するのか
タイムゾーン、カレンダー、書式化のせいでめんどくさくなっている
タイムゾーン：変換層をちゃんとつくる
カレンダー：ローカルな日時側を意識する
書式：Intl.DataTimeFormatで解決できそう